The statements in this section merely provide background information related to the present disclosure and do not constitute prior art.
Since its inception, the network is operated on the basis of the Authentication Authorization Accounting (AAA) system. Currently, the Remote Access Dial up User Service (RADIUS) protocol is one of the most prevalent AAA protocols, and is applied widely by virtue of its simplicity, security, manageability, and extensibility. However, the protocol is defective in transmission based on User Datagram Protocol (UDP), simple packet discarding mechanism, lack of retransmission rules, centralized charging services, and so on. Consequently, the protocol may not be suitable for the current network and thus may need further improvement. The Diameter protocol (which is an upgrade of the RADIUS protocol) includes: basic protocol, Network Access Service (NAS) protocol, Extensible Authentication Protocol (EAP), Mobile Internet Protocol (Mobile IP) protocol, Ciphering Message Syntax (CMS) protocol, and so on. The Diameter protocol supports authentication, authorization, and accounting of the Mobile IP, NAS request and mobile agent. Like the RADIUS protocol, the Diameter protocol is implemented through Attribute-Value-Pair (AVP), namely, a triplet of Attribute-Length-Value. However, the Diameter protocol specifies the error processing and failover mechanism in detail, applies the Transmission Control Protocol/Stream Control Transmission Protocol (TCP/SCTP), supports distributed charging, and overcomes many weaknesses of the RADIUS protocol. Therefore, the Diameter protocol is a AAA protocol more suitable for future communication systems and has been used by the AAA workgroup of the Internet Engineering Task Force (IETF) as a next-generation AAA protocol standard.
The Diameter protocol includes many types of Diameter nodes, such as, Diameter client, Diameter server, Diameter relay, Diameter agent, Diameter redirector, and Diameter protocol converter. The Diameter relay retrieves information from the Diameter request message, and decides the next-hop Diameter node to which the message is sent according to the contents of the domain-based Diameter routing table. The Diameter relay modifies the route information of the messages that pass through the relay, without changing other contents in the messages. According to the contents of the Diameter routing table, the Diameter agent decides the next-hop Diameter node to which the message is sent. Besides, the Diameter agent can modify the contents in the message. The Diameter redirector handles the routing configuration of the Diameter message uniformly without performing application-layer processing for the message. When a Diameter node sends a request message to the Diameter redirector according to the configuration but is unable to determine how to route the message, the Diameter redirector adds the routing indication information into the response of the request message according to the detailed route configuration information. Thus, clearly notifying the next-hop Diameter node. The Diameter protocol converter is adapted to implement conversion between the RADIUS protocol and Diameter protocol, or conversion between the Terminal Access Controller Access Control System (TACACS+) and the Diameter protocol. Various Diameter nodes set up network connections through configuration, or auto discovery or capability negotiation to make up a Diameter network.
In massive AAA application, the configuration management tasks are complicated with increase of the Diameter nodes. Therefore, the Diameter protocol provides mechanisms such as dynamic discovery of the node and capability negotiation, thus enhancing flexibility of the protocol and facilitating configuration and management. Diameter redirection is a type of simplified routing. It provides an effective way of centralized configuration, and is very useful in the case that the routes need to be configured in a centralized way. A redirector provides services for all members of a group, without being responsible for the task of message relay between domains. Such a solution is superior in that when the structure of one member changes, the group does not need to provide route update for other members.
FIG. 1 shows a system structure of Diameter redirection messages in the related art. The Diameter client (such as network access server) generates a service request message for the user “bob@example.com”, and sends the service request message to its Diameter relay. Supposing that the Diameter relay belongs to the “example.net” domain, the Diameter routing table of the Diameter relay lacks the routing ingress of the “example.com”, and its default routing configuration is a Diameter redirector, then the Diameter relay sends a redirection request message to the Diameter redirector. The Diameter redirector queries the stored routing configuration information to obtain the contact mode of the Diameter server capable of processing the service request messages sent by the Diameter client. Through a redirection response, the information on the contact mode of the Diameter server is returned to the Diameter relay. The Diameter relay sets up a transmission connection with the Diameter server according to the contact mode information, and sends the service request message to the Diameter server. In FIG. 1, the next-hop node of the Diameter relay is a Diameter server. If the next-hop node of the Diameter relay is another Diameter relay, the information on the contact mode of the other Diameter relay is obtained through a redirection request message.
According to the basic protocol of the RFC3588, after receiving the redirection request message from the Diameter relay, the Diameter redirector queries the stored routing configuration information, and generates a redirection response according to the information and returns the response to the Diameter relay, where the response carries route information. The route information is denoted by a Redirect-Host-Usage Attribute Value Pair (AVP) and a Redirect-Max-Cache-Time AVP. The Redirect-Host-Usage AVP is of the enumeration type, and indicates how the Diameter relay uses the contents of the redirection response. The Redirect-Max-Cache-Time AVP indicates the peer table created by the Diameter relay for the redirection host and the validity period of the domain-based routing table. Both AVPs guide the Diameter relay how to process the redirection route information. Table 1 provides a reference about how to use the two AVPs.
TABLE 1AVP valueMeaningDONT_CACHE0Default value, not bufferedALL_SESSION1All matching messages are sent to the hostALL_REALM2specified by the redirection response; theREALM_AND_APPLICATION3matching is based on the Session-ID, domain,ALL_APPLICATION4application, host, and user; in the non-zeroALL-HOST5response message of the Redirect-Host-UsageALL_UAER6AVP, the Redirect-Max-Cache-Time AVP mustexist, and is used for specifying the maximumseconds of buffering the redirection result.
In Table 1, when the value of the Redirect-Host-Usage AVP is the default mode “DONT_CACHE(0)”, it indicates that the receiver of the redirection response does not need to buffer the route information generated by the redirection response, and implies that all subsequent messages identical to the redirection request need to be requested from the redirector in order to obtain the redirection information. Other values of the Redirect-Host-Usage AVP indicate that the Diameter relay receiving the redirection response can buffer the received redirection message, and can forward the message directly along the route specified by the redirection message within a specific period (specified by the value of Redirect-Max-Cache-Time AVP) based on a domain, an application, certain sessions, or certain users, without the need of requesting the redirector. Upon expiry of the Redirect-Max-Cache-Time, the redirection route information in the buffer is deleted and the redirection request message is sent to the redirector again.
According to the foregoing method, in the redirection response returned by the redirector, all service messages with the corresponding route can be sent to the next-hop node “Redirect-Host” specified by the buffered route information directly in the subsequent part of the period if the value of Redirect-Host-Usage AVP is not DONT_CACHE(0). Namely, the domain- or application-based route information of the peer side can be buffered in a specific period, and in the specific period, all the service messages having the corresponding routing can be sent to the next-hop node specified by the buffered route information without sending any redirection request to the redirector again. In this case, when the route configuration information in the redirector changes, it may be very difficult to notify the node which has sent a redirection request message. The node which has sent a redirection request message sends a redirection request message to the redirector again to obtain the new route information only if the redirection route information expires or the next-hop Diameter node “Redirect-Host” fails which leads to impossibility of processing the service message. In cases where there is a strong requirement for real time message interaction and high Quality of Service (QoS), the related art has to wait for automatic expiry of the redirection route information at the end of the validity period of the redirection route information, which leads to application interruption and QoS deterioration.